All committers have signed the CLA.

Rebased, added lots of tests.

A few calls and conditions are missing still.

Already implemented the main part of the spec #3 for managing groups and memberships.

Next step: REPORT

I've added the REPORT as well:

Here is how to get one.
Put this into report-customgroups.xml:

<?xml version="1.0" encoding="utf-8" ?>
<oc:filter-members xmlns:a="DAV:" xmlns:oc="http://owncloud.org/ns" >
	<oc:filter-rules>
		<oc:user-id>user1</oc:user-id>
		<!--	<oc:is-admin>1</oc:is-admin> -->
	</oc:filter-rules>
</oc:filter-members>

Then curl -u admin:admin -X REPORT -H "Content-Type: text/xml" --data-binary "@report-customgroups.xml" 'http://localhost/owncloud/remote.php/dav/customgroups/'

Gives:

<?xml version="1.0"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:cal="urn:ietf:params:xml:ns:caldav" xmlns:cs="http://calendarserver.org/ns/" xmlns:card="urn:ietf:params:xml:ns:carddav" xmlns:oc="http://owncloud.org/ns">
 <d:response>
  <d:status>HTTP/1.1 200 OK</d:status>
  <d:href>/owncloud/remote.php/dav/customgroups/x/user1</d:href>
  <d:propstat>
   <d:prop>
    <oc:is-admin>0</oc:is-admin>
   </d:prop>
   <d:status>HTTP/1.1 200 OK</d:status>
  </d:propstat>
 </d:response>
 <d:response>
  <d:status>HTTP/1.1 200 OK</d:status>
  <d:href>/owncloud/remote.php/dav/customgroups/y/user1</d:href>
  <d:propstat>
   <d:prop>
    <oc:is-admin>0</oc:is-admin>
   </d:prop>
   <d:status>HTTP/1.1 200 OK</d:status>
  </d:propstat>
 </d:response>
</d:multistatus>

It basically returns the result for the CustomGroupMemberNode. I'm not too happy about this because it will not be useful for the UI. It misses the group display name and the group URI. Well, the group URI can be extracted from the result path.

I'd like to refine this separately once we start working on the UI.

• make it possible for regular admins to do the same things like group admins

The sad thing about adding this is that now I need to inject a group manager everywhere...

It basically returns the result for the CustomGroupMemberNode. I'm not too happy about this because it will not be useful for the UI. It misses the group display name and the group URI. Well, the group URI can be extracted from the result path.

please have a look at the carddav query request - there is a node where you select the elements which you expect to be returned ...

https://tools.ietf.org/html/rfc6352#section-8.6.3

     <D:prop>
       <D:getetag/>
       <CG:display/>
     </D:prop>

Are you kidding me...

Analysing /home/travis/build/owncloud/core/apps/customgroups/lib/composer/composer/ClassLoader.php

 1 errors

    line  317: == - is discouraged

App is not compliant

make: *** [test-codecheck] Error 101

Will need to exclude the composer stuff from the code checker

Squashed and removed the composer files I checked in by mistake from the other branch.

ownCloud admins can now also manage groups even when they aren't members.

Instead of passing around yet another object IGroupManaber, I created a helper class instead MembershipHelper which takes care of checking whether the current user can or cannot manage stuff based on their role and memberships.

@DeepDiver1975 please re-review.

My next step is to adjust the REPORT to implement pagination, but this could also be done separately if this PR is already mergable.

I'm feeling a bit lazy with the REPORT + pagination especially if I need to do it for all the different endpoints. So I came up with this generic paginated report idea, please check it out: owncloud/core#26840

REPORT will be done in a separate PR.

@DeepDiver1975 please review

• listing users does not work /remote.php/dav/customgroups/users/

listing users does not work /remote.php/dav/customgroups/users/

This is by design, same like the "users" list principal.

You need to know the user name you want to query.

This is by design, same like the "users" list principal.

Okay - in debug mode we allow listing of users in other collections as well

Okay - in debug mode we allow listing of users in other collections as well

Yet another code path to test / unit test and maintain. I'd rather not.

Unless we make it more useful by enabling user listing for any admins
And even then, the admin should be able to get a listing from the other endpoint.

Let me know what you think.

Adjusted exception formatting.

Added missing case: ownCloud admin can now enter the "users/$userId" subcollection even if not a member.

@DeepDiver1975 I'd like to not add user listing here, it would require injecting the user manager, etc. I don't think it's useful enough, especially if only used in debug mode.